Skip to main content

Plan de Gestión del Cambio

Logo FisioFind

FISIO FIND - PLAN DE GESTIÓN DEL CAMBIO


ÍNDICE


Ficha del documento

  • Nombre del Proyecto: FISIO FIND

  • Número de Grupo: Grupo 6

  • Entregable: #SPRINT 1

  • Miembros del grupo: Alberto Carmona Sicre, Antonio Macías Ferrera, Benjamín Ignacio Maureira Flores, Francisco Capote García, Daniel Alors Romero, Daniel Fernández Caballero, Daniel Ruiz López, Daniel Tortorici Bartús, Daniel Vela Camacho, Delfín Santana Rubio, Guadalupe Ridruejo Pineda, Julen Redondo Pacheco, Miguel Encina Martínez, Francisco Mateos Villarejo, Pablo Fernández Pérez, Ramón Gavira Sánchez, Rafael Pulido Cifuentes.

  • Contribuidores: Delfín Santana Rubio (autor), Julen Redondo Pacheco (autor), Antonio Macías Ferrera (revisor)

  • Fecha de Creación: 16/02/2025

  • Versión: v1.3


Histórico de Modificaciones

FechaVersiónRealizada porDescripción de los cambios
16/02/2025v1.0Delfín Santana RubioCreación del documento y primeros cambios.
18/02/2025v1.1Julen Redondo PachecoAmpliación y finalización del documento
18/02/2025v1.2Delfín Santana RubioCambios sugeridos en pull request
18/02/2025v1.3Antonio Macías FerreraCambios sugeridos tras la reunión del 08/03

1. NORMAS Y PROCEDIMIENTOS APLICABLES

Este documento es una continuación del apartado 4.5 del PLAN DE GESTIÓN DE LA CONFIGURACIÓN. En este plan se especifican los pasos a seguir para hacer un cambio. La finalidad de este documento es estandarizar un suceso tan importante como es el de la modificación no planificada. De no existir, este tipo de sucesos supondrían un riesgo y un punto crítico. Este plan es una forma de evitar ese riesgo.

2. PASOS A SEGUIR PARA HACER UN CAMBIO

Paso 1 - Registro del cambio

  • Se deberá recibir y registrar el cambio.

  • La solicitud de cambio puede venir de distintas formas:

    • Mediante el feedback que se da en las presentaciones.
    • Mediante las encuestas o feedback de los usuarios pilotos.
    • Mediante cambios sugeridos por el equipo de FISIO FIND.
  • La responsabilidad del registro del cambio será compartida y transmitida. Es decir, si un integrante del grupo es consciente de que ha recibido una solicitud de cambio, deberá transmitirla y registrarla.

  • La forma de comunicarla será a través de los medios utilizados por el equipo.

  • Se hará una Issue para registrar el cambio.

Paso 2 - Análisis del cambio

  • Se deberá asignar a un número de personas para que analicen el cambio y decidan si debe incluirse o no y cómo.

  • Si se creó una issue, esto deberá verse reflejado en la misma indicando su estado, por ejemplo, si el cambio ha sido aceptado.

  • Si no había issue, deberá crearse.

  • En caso de no aceptarse el cambio, el proceso de cambio acaba aquí.

Paso 3 - Modificación de registros e implementación del cambio

  • Se deberán modificar Issue e implementar el cambio siguiendo las formas generales.

  • Se notificará a los miembros del equipo sobre los cambios realizados.

  • Se deberá actualizar el estado de la Issue para reflejar el progreso de la implementación.

Paso 4 - Pruebas y validación del cambio

  • Se deberán realizar pruebas exhaustivas para asegurar que el cambio no introduce nuevos errores o afecta negativamente a otras funcionalidades.

  • En la Issue correspondiente, se deberá añadir evidencia de las pruebas realizadas, siendo estas capturas de pantalla, logs o cualquier otro elemento de importancia.

Paso 5 - Despliegue del cambio

  • Una vez validado el cambio, se procederá con su despliegue en el entorno de producción.

  • Se coordinará el momento del despliegue para minimizar impactos en los usuarios.

  • Se actualizará la documentación correspondiente y se notificará a los interesados sobre el cambio.

Paso 6 - Seguimiento y mejora continua

  • Se realizará un seguimiento del cambio en producción, para verificar que funciona según lo esperado.

  • Si se detectan problemas o se requieren ajustes, se abrirán nuevas issues derivadas para su análisis y resolución.

3. REGISTRO DE CAMBIOS

El registro de cambios se encontrará, en todo caso, en la sección de Issues del repositorio de GitHub de FISIOFIND. Este repositorio es público, así que el registro de incidencias pordrá ser visible para todos.

Ahí, las peticiones de cambios deberán ser siempre registradas ciñéndose a alguna de las siguientes plantillas en función de la naturaleza de la incidencia:

3.1. PLANTILLAS DE CAMBIOS

Plantilla de Pull Request

**Change description:**
Implement X functionality by adding X data related to requirement RNN-0NM...
- Change 1
- Change 2
- ...
**Motivation and impact:** - Improved ...
- Completed ...
- ...
**Instructions**
- Unit tests must be performed
- Ensure the change works correctly
- ...

Planitlla de Request For Change (RfC)

— Name: Change Request
About: Request a change on a functionality.
Title: ”[REQUEST FOR CHANGE] ”
Labels: [”bug”]
Assignees: []

**Description of the change:**
[Describe the change made, specifying what has been modified and how it affects the system.]
**Motivation:**
[Explain the reason behind the change, the problems it solves or the improvements it introduces.]
**Impact:**
[Describe how this change affects the system, users and workflow.]
**Instructions:**
[Include any necessary steps before or after applying the change, such as additional settings
or necessary verifications.]

Plantilla de solución de un Bug

— name: Bug Report
about: Report an error or problem in the code.
title: ”[BUG] ”
labels: [”bug”]
assignees: []

**Problem description:**
Implement X functionality by adding X data related to requirement RNN-0NM...
- Change 1
- Change 2 - ...
**Steps to reproduce:**
1. Go to ’...’
2. Click on ’...’
3. ’...’ happens
**Expected behavior:**
Explain what should happen.

Plantilla de solicitud de nueva funcionalidad

— name: Feature Request
about: Propose a new feature or improvement.
title: ”[Feature] ”
labels: [.enhancement”]
assignees: []

**Feature description:**
Implement X functionality by adding X data related to requirement RNN-0NM...
- Change 1
- Change 2
- ...
**Motivation and impact:**
- Improved ...
- Completed ...
- ...
**Additional considerations:**
Anything else we should know?
- Unit tests must be performed
- Ensure the change works correctly - ..